Service discovery is the mechanism by which hosts can automatically detect devices and services offered by these devices in a network. The issue is important both for conventional human orientated service and Internet of Things (IoT) applications. The problem is illustrated by the following examples. In a first example, a home user purchases a network printer for their home network. They wish to turn the device on, connect it to their network and start printing without specific network management expertise. They do not wish to force it to use a static IP address and manually configure this into their computer/tablet. In a second example, let us assume that thousands of IoT sensor devices are connected to a network and each is dynamically assigned an IP address. A processing function wishes to locate the devices so that it can process the data that they provide without having to manually configure large numbers of IP addresses.
A number of service discovery protocols have been proposed. However, DNS based service discovery is the most widely used presently and is able to provide functionality across the range of use cases from the home user example to the IoT case. Multicast Domain Name System DNS (mDNS) together with DNS based service discovery (DNS-SD) provide a simple means by which service discovery can be implemented with little dedicated equipment or experienced personnel to manage the functionality. A DNS is a hierarchical decentralized naming system for computers, services, or any resource connected to the Internet or a private network. It associates various items of information with domain names assigned to each of the participating entities.
Typically a conventional DNS server requires manual configuration of the zone files. This would be possible in say a large enterprise network where an IT professional would configure, for example, DNS records for the office printer to allow printing of files from anywhere in the office even if clients are not in the same LAN segment.
In the home environment this is not the case. A home user cannot be expected to populate DNS records or to manage naming of devices. To this end mDNS was developed. This enables DNS functionality to operate in the local link without a centralized DNS server (i.e. within a single LAN segment) using multicast transmissions.
Defined in RFC 6762. mDNS functionality can be briefly described as: providing the ability to perform DNS-like operations in the absence of any conventional unicast server. Thus the primary purpose of mDNS is to enhance name resolution in the local area network.
Due to the fact that mDNS operates only in the local link naming is not in the same form of as used in conventional DNS, where typical hierarchical domain name structures apply, such as ‘printer02.men67.virtuosys.com.’. Instead a new top level domain is defined, ‘.local.’. This new namespace results in host names such as ‘printer02.local’.
DNS-SD is a standardized protocol for describing and resolving services using DNS resource records. DNS-SD defines how a client can leverage standard DNS queries to discover service instances using PTR, SRV, TXT and A/AAAA records. The key innovation in DNS-SD is the use of indirection in PTR record querying which allows a host to browse for a list of available services. Thus, rather than finding a specific service a host can query for printers and get a response, indicating Lab printer, Office printer, meeting room printer etc. from which the host can choose the appropriate response. DNS-SD defines a structured service instance naming scheme to allow this to be accomplished.
The IETF homenet group (https://tools.ietf.org/wg/homenet/) has been working on the problem of complex modern home networks which involve multiple links with potential multiple external connections (e.g. ISP for general internet and another ISP for multimedia applications). With current technology, in these scenarios the home user is required to perform network management in order to ensure performance in the network. For example with multiple layer-2 links, mDNS functionality will not work across the whole home network. Also there may be IP address clashes etc. The home network group has produced RFCs in order to define auto configuration functionality of home networks so that networks configure themselves optimally without complex network management having to be performed. The RFCs that define the homenet functionality include the following.
RFC 7368 (‘IPv6 Home Networking Architecture Principles (HNAP)’), which provides the architecture and design requirements for homenet.
RFC 7787 (‘Distributed Node Consensus Protocol (DNCP)’). DNCP provides a framework for the mechanism by which peer nodes exchange state information about themselves in an efficient manner (as it is a consensus protocol that is optimized so that it requires the minimum of signalling when there is no change to the information). It allows a number of profiles to be used on top of the framework provide by DNCP.
RFC 7788 (‘Home Network Control Protocol (HNCP)’). HNCP is an extensible configuration protocol and a set of requirements for home network devices. HNCP is described as a profile of, and extension to, the Distributed Node Consensus Protocol (DNCP). HNCP enables discovery of network borders, automated configuration of addresses, name resolution, and the use of any routing protocol which supports routing based on both source and destination address. HNCP is a profile which sits on top of DNCP. It defines parameters which are important in controlling HNCP nodes within a home network, such as prefixes and IP addresses, service discovery, which nodes should perform DHCP for a particular link, etc.
RFC 7695 (‘Distributed Prefix Assignment Algorithm (DPAA)’). This RFC defines an algorithm for choosing a prefix to be used on a link from a pool of available prefixes so as to avoid a clash. Additionally a trickle algorithm (RFC 6206) defines a way in which low volumes of data are transferred efficiently during quiescent periods in the network.
The main purpose of HNCP/DNCP algorithms is to allow nodes to know the state of information in all of the other peer HNCP/DNCP nodes in the network.
HNCP defines a number of Type-Length-Value (TLV), which describes parameters such as the prefixes that a node has assigned to its interfaces, the IP address which the node is using itself, information about the external connection of network (only associated with nodes which are border routers, which may be referred to as a mesh edge node (MEN). Within data communication protocols, optional information may be encoded as a TLV element (sometimes referred to as a tag-length-value) inside a protocol. The type and length are fixed in size (typically 1-4 bytes), and the value field is of variable size. These fields are used as follows: Type: A binary code, often simply alphanumeric, which indicates the kind of field that this part of the message represents; Length: the size of the value field (typically in bytes); and Value: Variable-sized series of bytes which contains data for this part of the message.
The aim of the algorithm is to ensure that each node knows the current TLVs of all the other HNCP nodes in the network. However simply sending these TLV periodically is inefficient. Thus each node calculates a hash of its own set of TLVs and each of the TLVs for other peer nodes, these are called node hashes. Note also that node IDs are assigned to each node to identify individual node appropriately. It then uses this set of node hashes to create a network hash. This hierarchical hash functionality is illustrated in FIG. 1.
Referring now to FIG. 1, an overview of a known architecture 100 of a hash tree is illustrated. Each node 130, 132, 134, 136 creates a hash based on the information it wishes to publish in the network. Each node 130, 132, 134, 136 operates a consensus protocol, such as HNCP/DNCP, to ensure that all the nodes know all of the information, such as their internet protocol (IP) address, an assigned prefix and an indication of the node capabilities, etc. about their peers. In FIG. 1, node 3 134 is identified as a border router in the network (which may be referred to as a mesh edge node) as it has a backhaul connection to the Internet and may be further identified by border router information, such as a delegated prefix 135. The information from each of the HNCP/DNCP nodes 130, 132, 134, 136 is transferred 122 to a node hash function 120 that hashes node-specific data, prior to transferring 112 all node hash information within a network to a network hash function 110. HNCP/DNCP nodes 130, 132, 134, 136 are arranged to multicast a network hash 110 (to the all-homenet-node multicast address, ff02::11). Whilst each of the HNCP/DNCP nodes 130, 132, 134, 136 transmit the same network hash 110 a trickle algorithm ensures that there is minimal activity in the network (the rate of transmission is slowly reduced over time until a minimum level is reached).
When one of the HNCP/DNCP nodes 130, 132, 134, 136 has a change of information in its TLVs, then it will re-calculate its node hash 120 resulting in an update of its network hash 110. This new network hash 110 will then be multicasted to all other nodes. When a neighbouring node receives this new network hash 110, it will detect that this is different to its own network hash 110 and it will use unicast signalling to request the node to send its node hashes 120. The neighbouring node will then inspect the node hashes 120 and then request the full node data for the node ID, which has a different hash than the one that it has stored. Note that sequence numbers are used so that the newest hash is detected. The node then sends the full node data (using unicast) for the requested node to the neighbor node.
This new data can then ripple through the network so that all nodes 130, 132, 134, 136 know the new TLV data and, thus, all nodes 130, 132, 134, 136 have the same network hash 110, which they all multicast, i.e. a new steady state is reached in the network where everybody has the up to date information.
Once nodes have up to date information about their peer group that they can then make sensible decisions themselves about their own configuration. For example, when they know the prefixes that other nodes are currently using, they themselves can then avoid assigning these prefixes to their own interfaces.
A known problem with such mDNS/DNS-SD functionality is how to operate efficiently in a small multi subnet network. A wireless mesh network 200 is used in FIG. 2 to illustrate this problem, where each node acts as a router and allows external devices to connect to the network using wireless connectivity. Although the problem is explained with respect to a network using wireless connectivity, it could equally well apply to a home network case where router devices are used that are connected by wired technology, such as powerline or Ethernet again allowing an external device to connect by, say, WiFi™ or other means. In these constrained network scenarios mDNS is appropriate, because of its simplicity. However, mDNS cannot be used as it is designed to only work in the local link, i.e. across a single subnet.
The wireless mesh network 200 includes a backhaul connection 212 connecting a border router (mesh edge node (MEN)) 220 in the network to, say, the Internet 210. The MEN 220 is connected 231 to a messaging server 230. The wireless mesh network 200 includes a number of internal routers (sometimes referred to as mesh nodes (MNs)) that provide routing functionality in the wireless mesh network 200, but do not have a backhaul connection. The MN devices in the wireless mesh network 200 have WiFi™ (or other wireless technology) functionality, separate to the mesh interconnects, which allows external devices to connect to the wireless mesh network 200. For example, a first MN#1 222 of a first network area 242 includes a first smartphone#1 252 and a network-enabled speaker 253 and is coupled 235 to the MEN 220. A second MN#2 228 of a second network area 248 includes a network-enabled printer 258 and is also coupled 236 to the MEN 220. The second MN#2 228 is also coupled 233 to an Internet of Things temperature sensor processing server 232, arranged to process temperature sensor data. A third MN#3 224 of a third network area 244 includes a Internet of Things temperature sensor 254 and is coupled 237 to the second MN#2 228. A fourth MN#4 226 of a fourth network area 246 includes a second smartphone#2 256 and is also coupled 238 to the second MN#2 228.
Each of the internal routers/internal edge routers (MN/MEN) 220, 222, 224, 226, 228 includes, say an 802.11 access point (AP) or 802.15.4 or IPv6 enabled Bluetooth™, etc., which allows external host devices to connect to the device.
In operation, first smartphone#1 252 wishes to use the network-enabled speaker 253. The network-enabled speaker 253 is connected to the same access point (AP), namely first MN#1 222, as the first smartphone#1 252. Thus, they both use the same local link. Thus, conventional mDNS/DNS-SD can be used by the first smartphone #1 252 to discover this network-enabled speaker 253; as mDNS only works in the local link and no modification is required to the router nodes or any of the client devices.
However, if second smartphone#2 256 wishes to use the network-enabled printer 258, it is unable to use conventional mDNS/DNS-SD. This is because these two clients are connected to different APs, i.e. in fourth MN#4 226 of fourth network area 246 and in second MN#2 228 of second network area 248. Hence, they are in different local links and, thus, multicast DNS queries sent from the second smartphone#2 256 will not be routed to the second MN#2 228 and then on to the network-enabled printer 258.
A mechanism is required to allow mDNS-equipped hosts to communicate between each other in the mesh, i.e. a mechanism is needed to find the IP address of the network-enabled printer 258 located in another AP.
A similar problem occurs with the IoT temperature sensor 254, which needs to find a server on which its measurements can be processed. The measurement processing server resides in or is coupled to) second MN#2 228, which is not in the same local link as the IoT temperature sensor 254. A solution using simple mDNS at the IoT temperature sensor 254 is again needed.
A further similar problem occurs when first smartphone#1 252 and second smartphone#2 256 wish to talk to each other via a messaging server that is located on the MEN 220. Again the problem is for the first smartphone#1 252 and second smartphone#2 256 to find the IP address of the service (via the message server) that they want, although it is not in the same local link. However, this time the service does not reside on an external device but is located on (or coupled to) a router node, namely MEN 220.
Thus, it would be useful to enable all devices to communicate to all other devices within the network and external to the network, and each of the devices to perform the same functionality as some of the other devices, a mechanism to manage this complex cross-functional operation is required. It would also be useful to see all of these services across the whole of the mesh (or home network or any other constrained multi-hop network). These services cannot be seen using this conventional technology, except if the service is located in the local link supported, e.g., connected to the same AP.
One Known solution to this problem is to use a hybrid unicast/multicast DNS-based service discovery (for example as described in https://tools.ietf.org/html/draft-ietf-dnssd-hybrid-03). The hybrid unicast/multicast DNS-based service discovery relies on hybrid functionality residing on the HNCP nodes (router nodes in a small wireless mesh network), in order to discover multicast DNS records on its local link, and make corresponding DNS records visible in the unicast DNS namespace. This functionality is illustrated in the mesh architecture 300 of FIG. 3, which describes a Hybrid unicast/multi-cast DNS, as proposed by Cheshire in an experimental RFC.
The mesh architecture 300 includes a backhaul connection 312 connecting a border router (mesh edge node (MEN)) 320 in the network to, say, the Internet 310. The mesh architecture 300 includes a number of internal routers (sometimes referred to as mesh nodes (MNs)) that provide routing functionality in the mesh architecture 300, but do not have a backhaul connection. For example, a first MN#1 322 is coupled 335 to the MEN 320 and arranged to cover a first network area 342 (subnet) that includes a first smartphone#1 352. A second MN#2 324 is coupled 336 to the MEN 320 and arranged to cover a second network area 344 (subnet) that includes a network-enabled printer 354.
In the hybrid unicast/multicast DNS-based service discovery of FIG. 3, a (client) first smartphone#1 352 sends a unicast DNS query 362 for printers in a specific domain. This is sent to its local DNS server (which is in fact a hybrid proxy) on first MN#1 322. Conventional recursive DNS functionality is used so that the query is forwarded 372 until it reaches the delegated authoritative name server for the appropriate domain, namely the hybrid proxy at second MN#2 324.
The hybrid proxy at second MN#2 324 can consult its mDNS cache (not shown) to see if it has a record that is appropriate to answer the query (just as a conventional DNS server would consult the resource records (RRs) that it is authoritative for). However, in this case, there is no appropriate cached information. Therefore, it issues a mDNS query where it translates the query from_printer._tcp.mn2.men8912.vmesh.com. 365 to_printer._tcp.local 364. This mDNS message is then multicasted in the subnet associated with second MN#2 324.
The printer then responds to this PTR query by responding with is name ‘lab printer’. This PTR response is sent again using multicast DNS. The hybrid proxy at second MN#2 324 then converts this back to unicast DNS (appending it's delegated domain) and this is sent back to the smartphone, via the DNS function at first MN#1 322.
As discussed above one obvious question which arises is how does the client smartphone device know that it should query the ‘mn2.men8912.vmesh.com.’ domain? The answer is domain enumeration. This is a feature of DNS-SD as described in section 11 of DNS-SD specification at RFC6763, which provides clients with recommendations on which domains to browse for service. The client sends a PTR query for defined record names, these include the following: The browse domain, which uses the PTR b._dns-sd._udp. This is a list of domains which to browse for services, i.e. RRs in the DNS server with this string would contain a list of domains.
The default domain, which uses the PTR db._dns-sd._udp. This is a single default domain on which to browse for services.
The legacy browse domain—lb._dns-sd._udp. The hybrid proxy will respond to queries sent to PTR with the above strings for both the unicast and multicast case. In this known example these records at the DNS (for the multicast case) might look like:                b._dns-sd._udp. PTR mn1. men8912.vmesh.com.                    mn2. men8912.vmesh.com.                        db._dns-sd._udp. PTR mn1. men8912.vmesh.com.        lb._dns-sd._udp. PTR mn1. men8912.vmesh.com.        
Note that clients typically learn the location of their home DNS server address and home DNS home domain name by means of DHCP options, see RFC 2132 (code 6=DNS address, code 15=DNS domain name).
The inventors have identified that there are three main problems with hybrid proxy mechanism of FIG. 3, when used in a small wireless mesh network.
First, there is a need to assign domain names to links. In home networks and small wireless mesh networks it shouldn't really be necessary to do this; nodes in these networks can be added dynamically due to new devices appearing or changes in the radio environment, in the case of wireless mesh networks, to have to dynamically add domain names and to manage them autonomously is problematic when there is no real benefit to be obtained.
Secondly, the clients must have some picture of the mesh. When domain enumeration is carried out the client is presented with a list of domains on which to browse, which should be chosen is not obvious.
Thirdly, the architecture of home networks and small wireless mesh networks is such that there really isn't any need to have separate domains within any of the links in the mesh. The proposal means that the functionality is unnecessarily complex.
A solution is therefore required for allowing service discovery using mDNS to operate in small multi subnet networks, such as wireless mesh networks.